Listing integration #27
Conversation
rekibnikufesin
requested review from
robrobbins and
thirtyaughtsix
and removed request for
robrobbins and
thirtyaughtsix
|
Does weird shit happen if we send more than 1 file? The code allows for it but it looks like the |
| voteBy = evt['args']['voteBy'] | ||
| if voteBy > int(time.time()): | ||
| owner = evt['args']['owner'] | ||
| return owner |
There was a problem hiding this comment.
once we recieve the transaction_hash from the client we can do 2 things:
- use web3.py to
wait_for_transaciton_receipt(that way we know its mined) - use protocol's
voting_contract.is_candidate(hash)
There was a problem hiding this comment.
one question this raises is
should we implement twisted/celery/whatever to handle doing this in threads?
| constants.CANDIDATE_ADDED,{'fromBlock':0,'toBlock':'latest'} | ||
| ) | ||
| events = voting_filter.get_all_entries() | ||
| for evt in events: |
There was a problem hiding this comment.
i can prob abstract out some log_helpers in datatrust
| if event_hash == listing_hash: | ||
| log.info(f'Listing {listing_hash} has been listed as a candidate in protocol') | ||
| voteBy = evt['args']['voteBy'] | ||
| if voteBy > int(time.time()): |
There was a problem hiding this comment.
there is also already a voting_contract.poll_closed(hash) for this
depends on if we are gunna grep logs or not. for this i don't think we need to - can prob just get away with the 2 getters... we'll see
Yeah, good catch. Weird shit would happen. The DB schema is only expecting one file and you're right about the data_hash. |
Adds the following checks:
Listing candidate file asset is saved into
s3_bucket/{public_key}/{listing_hash}to minimize name collisions.